A computer filesystem can generally be thought of as an organized collection of entries. Each entry in the filesystem can either be a file or a directory. A directory itself can contain additional entries whereas a file cannot. A special directory, commonly called the root directory, contains all the entries of the filesystem in a nested tree-like manner. Thus, every entry in a filesystem with the exception of the root itself is contained in a directory.
When an entry is created, it is usually given a name in a specific namespace that is unique among the names of other entries contained within the same directory. Thereafter, filesystems with multiple namespaces typically generate corresponding names of the entry for each additional namespace maintained by the filesystem. An attempt is made by the filesystem to generate names which are as similar as possible to the original name of the entry. Again, each corresponding name which is generated in the multiple namespaces is unique from the names in the corresponding namespace of other entries contained within the same directory.
A path to an entry is a sequence of names which identifies an entry. If the path is a sequence of names starting from the root directory, then the path can be considered an absolute path. Otherwise, the path is considered to be relative to some other entry. The last component of a path can be referred to as the tailname of the entry while the directory which contains the entry is referred to as the base entry for the entry.
Problems may arise in maintaining the integrity of filesystems with multiple namespaces. Unique names in multiple namespaces, each having their own syntax requirements, must be maintained as well as any rules the filesystem has relating to the interaction between the multiple names of entries in the various namespaces. This problem is typically compounded in a networking environment.
For example, in a typical network system, groups of devices, such as computers, printers and other computer peripherals are communicatively coupled together to provide resource sharing and/or data sharing. Resources and data are shared by allowing these network devices, referred to as nodes, to communicate with other nodes on the network and to request or offer data and services from or to other nodes. Network servers are common network nodes which allow other nodes, such as network clients, to access files stored on the network servers.
For maximum versatility, it is desirable for the network servers to allow many different types of network clients to access the server's files. However, each different type of network client commonly has its own syntax rules governing the manner in which files are accessed and identified. For example, a client running in the Microsoft.RTM. MS-DOS.RTM. operating system environment has syntax rule limiting the maximum number of characters which can be used to identify an entry to 11 (known as the 8.3 format), whereas a client, for example, running in the IBM.RTM. OS/2.TM. operating system is not so limited.
As a result, network servers which allow multiple types of network clients to access the same files must accommodate the file syntax rules of the various clients. Accordingly, for each commonly accessible file maintained at the network, the network server creates and maintains a name mapping table containing a separate filename for each of the distinct syntax requirements of the various clients. The collection of filenames at the server associated with one specific client type is often referred to as the namespace of that client.
When a file is saved by a client using its particular namespace, the server updates a name mapping table it maintains and, as described above, creates additional syntactically correct names of the saved file in the other namespaces as well. For example, if an IBM.RTM. OS/2.TM. client saved a file named "very.sub.-- long.sub.-- file.name" on the server, the server would create a unique MS-DOS.RTM. name for the file such as "very.sub.-- lon.nam" so that other MS-DOS.RTM. clients connected to the server would be able to access the "very.sub.-- long.sub.-- file.name" file created by the IBM.RTM. OS/02.TM. client. Similarly, the server would create other unique names for the file in any other existing namespaces (such as Apple.TM., Unix.TM., etc.) and store the unique names in the name mapping table. This process is called "mapping." If, for example, the MS-DOS.RTM. name "very.sub.-- lon.nam" already existed on the server, then the mapping process would pick a different name for the MS-DOS.RTM. namespace, e.g. "very.sub.-- lon.na2." If the name of an entry is subsequently changed after being created, then the mapping process typically would be performed anew and each of the namespaces would be updated.
The above scheme for maintaining network namespaces, while generally workable, has certain drawbacks and deficiencies. Specifically, existing network servers typically expect only one namespace per client and thus provide support for operations directed to one namespace at a time. As a result, such network servers cannot fully serve clients running an operating system which supports multiple names of files, such as Microsoft Windows 95.
This problem is compounded by the fact that existing network servers typically will be unaware of any interrelationships between the syntax rules of the multiple namespaces on the network client. As a result, names given entries in the namespaces of the server may not match the names given the entries in the corresponding namespaces of the client's local filesystem. Filename integrity may be compromised or wholesale incompatibility may arise since the client may be unable to access files in the namespaces of the server.